Can't start T265 in seperate thread

[mbechard]

Required Info
Camera Model	T265
Firmware Version	0.1.0.242
Operating System & Version	Win 10
Kernel Version (Linux Only)
Platform	PC
SDK Version	2.29.0
Language	C++
Segment	AR

Issue Description

Using simple setup code, I'm unable to get the T265 started if I do this work in a thread. It works fine in the main thread though.
rs2::pipeline pipe; rs2::config cfg; cfg.enable_stream(RS2_STREAM_POSE, RS2_FORMAT_6DOF); try { auto res = pipe.start(cfg); } catch (rs2::error &e) { std::cerr << e.what() << endl; return false; }

All the other devices start fine in this other thread (using different setup code), just the T265 has this issue. Error is usually 'No device connected'. RS Viewer app and other sample apps work fine though.
Is there any per-thread requirements for it? Anything about the T265 that would explain the difference?
Thanks

[MartyG-RealSense]

The link below discusses at length the subject of using separate threads with T265.

#4163

A summary of the conversation would be: (a) if you are using T265 and depth cameras such as the D435 or D415 together, put them all in the same thread if possible; and (b) multiple T265 in separate processes is not currently supported.

Also, if you are using a D435 with a T265, make sure the D435 does not activate first before the T265.

[mbechard]

Thanks for the info! I've looked through this and although similar, I'm not quite in this situation. In my current test I'm not using another camera (no other RealSense is connected to the machine).

However the other limitations do in general make the T265 unusable for us since multiple threads would be needed for performance, and controlling the order that RealSense nodes are created in the software isn't possible since it's a user action.

[MartyG-RealSense]

You may get better performance if you alter the frame queue size. You can reduce latency this way, though at the trade-off of a higher risk of dropping frames.

https://dev.intelrealsense.com/docs/frame-management#section-frame-drops-vs-latency

[mzelina]

Have you tried using the callback mechanism?

void t265Callback(const rs2::frame& frame)
{
	if (rs2::pose_frame pf = frame.as<rs2::pose_frame>())
	{
		auto pose_data = pf.get_pose_data();
		/// Do something with pose_data
	}
}

Then, when you initialize the camera:

                rs2::pipeline pipe;
	        rs2::config cfg;
		// Add pose stream
		cfg.enable_stream(RS2_STREAM_POSE, RS2_FORMAT_6DOF);
		// Start pipeline with chosen configuration
		pipe.start(cfg, t265Callback);

[ev-mp]

@mzelina , it is possible to open multiple T265 each in a separate threads. The caveat is that you must share the initially created context object among all the pipe instances.

This is a known limitation of T265. See the link.
#3734, #3434, #3437, #4183

[mbechard]

That's really great info. It would be great if the exception said this as I bet this ends up being my issue

[mbechard]

@ev-mp What are the ramifications of sharing contexts between pipelines for other devices? I have one thread that is responsible for enumerating the cameras, which is what creates the context. Currently this context isn't used by the other threads (one thread per camera), and this works for other cameras such as the D-series. Should I

1. Have the context shared in all cases between all cameras?
2. Only share the enumerating threads context with T265 cameras?
   Thanks

[ev-mp]

@mbechard, sorry for the delayed response.
From the user's perspective it is transparent whether the context is being shared (except for T265).
For Dxx-series it makes no difference indeed, but since you're also using T265 I would recommend to stick to a single mode of operation, i.e. make a single context object and share it among all threads/device including D4xx. This will remove any chance of race between context instances created from different threads
Note that in addition to passing context by reference (you must not pass by value, as it will copy) you can also wrap it with shared_ptr to avoid potential life-time management issues.

[mbechard]

@ev-mp, great that's very helpful. One clarification though, isn't the rs2::context already implicit a shared_ptr for the rs2_context, so passing it around by value should be fine, no? Thanks!

[RealSenseCustomerSupport]

---

I believe that's correct @mbechard.

Has this issue been resolved? Are you able to bring up the T265 up in it's own thread now?

[mbechard]

Yep, using this workaround I'm able to open up the T265 now. Thanks!

[bfulkers-i]

For those that encounter this bug in the future, once #5213 is released you should be able to use T265 from it's own thread or process as with D4XX.

[MartyG-RealSense]

@bfulkers-i Thanks so much for your work on this!