startup ordering

[mjsobrep]

Feature Request: build a startup ordering component into realsense ros, essentially be able to give an index to each camera and each camera will come up in succession, waiting for the prior index to be set up before trying to start.

There have been numerous reports of the order of realsense cameras starting being important. There are also a number of reports of starting more than one realsense camera at once causing problems. It would be great to have a clean way built into the realsense-ros launch framework to to specify the order to bring up cameras and how long to wait between one camera being fully up and starting to search for the next one.

This functionality can be approximated with some bash scripting, but built in support would be great.

[MartyG-RealSense]

Hi @mjsobrep Thanks so much for your request. I have filed an official feature-request report with Intel so that the RealSense team can consider whether or not to take up the idea. This case should be kept open whilst the requst is being considered. Thanks!

[amilcarlucas]

Any progress on this?

[MartyG-RealSense]

The ROS wrapper developer is aware of this change request. I cannot offer further comment on the subject though.

[doronhi]

Sorry I failed to respond.
Events when multiple process try simultaneously to access the same device should not be handled by a script, and not by realsense2_camera but by the driver layer, i.e. by librealsense2 library.
Of course, in reality there are issues that still need to be addressed and I expect users manage some of them by ordering the startup of the nodes.
I don't think, however, that the wrapper should officially include such a workaround.

[mjsobrep]

I am talking about trying to access multiple devices. Currently if two realsense cameras are started at the same time, the rate of failure is much higher than if one is started, there is a delay, and then another is started. This could be a result of high power consumption, something in the communications, or some other quirk. Others have reported that the order of starting cameras is important (I have not confirmed this). Regardless, it would be great if the startup order for each independent device could be specified and only once a camera is up and publishing does the next camera launch.

[MartyG-RealSense]

Hi @doronhi Do you have any further comment about the message of @mjsobrep above please? Thanks!

[doronhi]

Not really.
I understand the realities and if such a launch file that allows startup ordering works for you I will be happy, on behalf of the community, if you share it.
Still, I consider it a workaround and not the real solution.
I posted a [remark|https://github.com//issues/1187#issuecomment-759367599] where I suggest to try a different, more reliable perhaps, backend. For other cases there may be other solutions or real issues that need to be solved.
I currently don't think that developing and maintaining a mechanism for startup ordering is on the shelf.

[MartyG-RealSense]

Thanks very much @doronhi for pointing @mjsobrep towards #1187 (comment)

At this point I will close the case, since startup ordering is not a planned feature and you have pointed @mjsobrep towards a next step to look at. Thanks again @doronhi for your help!

[doronhi]

I spent some time reconsidering.
I believe these issues should be dealt with within librealsense2 and I would like to avoid adding workarounds and "voodoos" into the wrapper.
But the fact is that I can't tell when these issues will be rooted out and the wrapper needs to be as stable as possible right now.
I would like to know if using v4l backend, as I suggested works, if loading multiple cameras simultaneously is now more stable. If not, for dealing with the root cause I would like to know, in separate issues, the scenario (Machine type, OS, cameras type and versions, usage of usb-hubs etc.), (The case in #1187 with @d415, NUC, Ubuntu16 is a good example)
In the meanwhile, if a PR is submitted, I will consider it approvingly.

Sorry @mjsobrep, @MartyG-RealSense for giving you a hard time and thanks for your persistence.

[MartyG-RealSense]

No problem at all @doronhi - I have removed the DSO-15577 tag from the case (referencing the previous now-closed change request) to avoid future confusion.

I have not seen any cases involving multicam start-up order for months now, so there may not be a compelling case for an official change request on the librealsense side. That certainly does not prevent RealSense community members from submitting their own PR for the RealSense ROS wrapper to address the issue though.

Let's leave this case open for a further time period and see if anyone else offers an opinion and / or a PR.

[mjsobrep]

I will try to do some more testing on this in the next few months. I strongly suggest that it is a power draw issue where in many situations two cameras starting up at once will just try to draw two much power to both run properly. When I get the time, I will measure the power draw on startup, but it will be a couple of months. I'll also try to see if the newer versions are more stable making sure to use v4l. In the past, even when using v4l, I have had problems. I moved to using a shell script to guarantee that multiple cameras do not come up at once. It is inelegant, but works, so I have not been having this problem lately.

[MartyG-RealSense]

Hi @mjsobrep If it is a timescale of months then I would rather close this case temporarily (preserving the history of the comments made so far), and then you would have the option of re-opening it when you are ready to begin your tests. Does that sound acceptable to you, please? Thanks!

[MartyG-RealSense]

Case closed due to no further comments received.

@mjsobrep As suggested above, feel free to re-open this case using the Reopen Issue button under the comment box at a future date if you return to your project.