T.265: My experience after about 3 months

[neilyoung]

I decided today to give up after about 3 months of intensive work with the T.265. For me personally the camera, especially its software, is not ready for production yet. My dilemma is that I would have a nice little application for the camera (https://neilyoung.github.io/t265pose/), but the currently unsolved (and possibly never solved open problems) prevent me from continuing work, let alone beta delivery with a clear conscience.

The current version 2.32.1 is, in my opinion, just too buggy to rely on, but unfortunately it is exactly the one I would need for my application. I'm long past the nerd stage of dealing with this camera, I'm just not satisfied with fancy short youtube clips that promise that everything will be fine.

I think you can expect a higher degree of maturity from a 2.x version after all. I don't attack anybody personally, on the contrary, I appreciate very much the engagement of people like @radfordi , @ev-mp , @MartyG-RealSense and others, but that doesn't bring me one step closer to solving problems that are open to me.

As of today I see unresolved issues in

• the faulty map storage function (T265: Attempt to save a map very often ends in "null pointer passed for argument "buffer"" #5683)
• a regression in the behaviour of the frame callbacks, which lead to an accumulating delay (T265: Regression with version 2.32.1 on macOS #5709)
• USB problems on platforms that were running before (T265: Again USB problems, now with Banana PI M2 Zero #5650)
• problems with the Android connection (Android support for t265  #5681)

Nevertheless I closed all my open issues due to lack of interest. I just can't wait for solutions now. I put this great camera, this promise of a turn-key solution, aside and wait for better times. It's too bad that the T.265 obviously doesn't get the same attention as the other depth related cams. But I can't and won't have to deal with this uncertainty anymore. My idea of a product is discontinued now.

I hope you all don't get me wrong. I was really willing to make it a success. Up to now it didn't work for me. Maybe time will come.

Good luck

[neilyoung]

Sorry for the typos.

[neilyoung]

...at least a troll did care...

[MartyG-RealSense]

I did read your comments but didn't feel qualified to provide feedback to your points, as I'm not a T265 specialist.

[neilyoung]

Thanks @MartyG-RealSense. I still have the hope, that I can resume soon and that all my problems will be solved :) Keep on doing your great job, all of you.

[radfordi]

Hi @neilyoung,

Thanks for your frank feedback and for all the bug reports you've given us to date (all 44 of them). We really do appreciate them. In particular, we appreciate your self-contained programs that reproduce many of the issues you've found!

We know it can be frustrating when there are regressions. We did expect a few after #5213 was merged, given the scope of the change.

We are working on most of the issues you've reported, even if we don't always provide up-to -the-minute feedback on our progress. Even the ones you closed out of frustration. :)

[neilyoung]

@radfordi Hi Jim, thank you so much for your kind words. I'm happy that the show is going on. I really like that cam, IMHO it is really a turn key solution.

44 issues, really? Wow... didn't expect that.

Thanks for the positive outlook. I will continue watching this site and will be available, if required. Let me know.

Regards

[zainmehdi]

@neilyoung @MartyG-RealSense . A bit off topic but please pardon my ignorance. I had been working with transformation matrices for my app and was mostly using eulers. I saw trajectory example and there is multiplication by 180 degrees around y-axis. I couldnt understand the need for this. The quaternion transformation matrix on this website quotes the relation without any negative sign. Is it because quaternion derivation takes z axis out of the plane and and x axis towards right and rotating by 180 degrees align it with t265's coordinate frame ? And was there any specific reason for choosing T265's coordinate axis the way they are? Can you please give me any hints on that. Thanks a lot.

[neilyoung]

@zainmehdi Please try to clarify your question and push it again on a separate thread. You are on the right track with homogeneous transformation matrices. I suggest you to make you a little 3D model. I made mine from three pencils which I glued together, see https://neilyoung.github.io/t265pose/. This helps a lot to not get lost with all the possible rotations. You will be able to find the required rotations around which axis to come from one reference frame to another. I can't comment on the T.265 choice, but it is surely a valid choice, most likely caused by technical reasons.

[zainmehdi]

@neilyoung Thanks alot I checked your blog and it was really helpful.

[neilyoung]

@radfordi I'm opting out this repo now. Would be nice if you could give me a ping once there is something to test for me. TIA

[neilyoung]

@radfordi 25 days later the question: Is there any improvement to be reported on all these issues?

TIA

[yputra]

@neilyoung I have the same idea too, to make a simple heap device with Raspberry Pi 4... but it still has problem when I use both the T265 and D435... in the previous releases earlier than 2.32, it crashes after 10 minutes or so with this error

FW crashed - got error in stream endpoint thread function: status = -1 (LIBUSB_ERROR_IO), actual = 0

but now in 2.32 and 2.33, they just crash without and error warning or anything, its just the T265 crashed and stopped publishing pose data, hence the whole system also stopped (mapping, etc.). Hope it will get solved in the future when I decided to go back into this again... (when there is new release in the future, I hope they are not going to abandon this issue...)

[neilyoung]

I finally open sourced my results https://github.com/neilyoung/t265-realsense-poc-application