librealsense: D435 intermittantly fails to appear on lsusb after boot and reboot

Required Info
Camera Model	D435
Firmware Version	5.9.9.2
Operating System & Version	Linux (Ubuntu 16.04)
Kernel Version (Linux Only)	4.8
Platform	Intel NUC 7i3BNH
SDK Version	2.10.3

Issue Description

When trying to use 2x D435 with a 7th gen i3 NUC, I found that sometimes the devices failed to show up after a reboot cycle.

I automated both a reboot test:

1. reboot on a cron job with logging on a service that launched and monitored the D435 ROS node output
2. powered the NUC using a relay that cycled 15 seconds off, 5 minutes on (same service+logging)

The service used the ROS pipeline with only depth enabled. One pipeline per camera. The only modificiation to the current release branch is this reset the camera whenever the driver launches: https://github.com/ethz-asl/realsense/commit/148eaf93b4ad9f7d795ddce42f6bfae4e7e52533

I have experienced three issues:

1. The device fails to show up (1 or 2 devices missing from lsusb) This is the primary issue that I am concerned about.
2. The ros node can’t talk to the camera without a reset after a ‘bad’ shutdown (resolved by the above patch). This issue can also be manually “fixed” by issuing the reset in the realsense-viewer each time it happens.
3. The pipeline launches but crashes or otherwise does not emit data shortly after launch. It sometimes emits data for a second or two. (I haven’t investigated this one much).

After finding a workable solution for problem 2, I set out to profile problems 1 and 3.

• Problem 1 can be “resolved” by rebooting or power cycling the machine. This is not desirable.
• Problem 3 can be handled by adding a watchdog that resets the entire affected pipeline (kills the process tree and relaunches the launchfile). My guess is that this is a problem in either librealsense2 stability or the ros node stability.

I profiled this a lot to try to understand the problem and work around it:

hardware	kernel	firmware	usb config	test #	issue 1#	issue 3#	conclusion
NUC7i3BNH	4.8.0.36	5.9.2.0	usb c, usb a	211	29	13	only usb a camera experiences reset issue, maybe usb c port is immune
NUC7i3BNH	4.13.0.58	5.9.2.0	usb c, usb a	104	28	6	kernel 4.8 and 4.13 both experience this problem
NUC7i3BNH	4.8.0.36	5.9.2.0	both usb c, Kensington CH1000 hub	242	0	23	USB c hub can resolve issue 1
NUC7i3BNH	4.8.0.36	5.9.2.0	both usb c, Ankler hub	149	1	64	usb c hub does not always resolve issue
NUC7i3BNH	4.8.0.36	5.9.9.2	both usb c, Oricos hub	1	47	0	some hubs really don’t work
AsRock IMB-195 i7-6700TE	4.8.0.36	5.9.9.2	both USB A	1466	733	1737	The D435s are very unreliable with this computer.

In that last case, there is a fairly reliable pattern.

• 20 reset cycles: Cameras worked on two consecutive boots
• 1466 reset cycles: Cameras alternated, first working, then on the next reboot did not work