Hey @kromerf, good questions.
In many cases it’s required for a proper application startup that nodes are started in a controlled way (correct order, dependent on a node specific status send to a “overall application server” node, etc.).
I’m a ROS guy as well, and you’re right, this isn’t uncommon, but I personally consider it a bug. Your life will always be hard until your ROS nodes gain the ability to wait for proper state, and trying to order your services is a workaround, not a solution. That said, let’s discuss your questions:
You’re correct, snaps don’t have such a mechanism. Snaps don’t really have the concept of dependencies that such a function would require. There was a proposal a while back about being able to order cross-snap services, but I’m not sure that ever went anywhere. @mborzecki, do you have any more information on that?
It can be tempting to come from ROS’ concept of nodes and want to create a snap of each node, but I don’t recommend it. You’ll end up with a lot of dependencies duplicated between each snap, and updating them will be a nightmare as it will be easy to get into the situation where a given message definition changed in the snap publishing, but not the snap subscribing.
I instead suggest approaching each snap as a standalone product, each of which uses ROS 2’s launch system to bring up the collection of nodes contained within it. Depending on your use-case, the simplest option is to put your entire ROS system into a single snap that can be transactionally updated in one go. If that doesn’t work for you, you can still split your ROS 2 system into multiple snaps, but I suggest trying to avoid coupling them too closely.
As a simple example, your UAV could have three snaps that are configured to work together without duplicating a lot of dependencies:
- A “foundation” snap that contains base behavior: nodes that read from various sensors and and control the servos. This might contain a mux configured for being controlled via two topics, one from a teleop system and one from an autonomous navigation system.
- A “teleop” snap responsible for communicating with whatever RC system exists. It publishes one of the topics being muxed into the “foundation” snap.
- A “navigation” snap responsible for mapping and autonomous navigation. It publishes the other topic for the “foundation” snap.
You can see how these snaps are split by concern rather than node, and none strictly depend on anything being launched by anything else. All three can use ROS 2’s launch system to bring up its collection of nodes. You still need to be careful to update them in lockstep if you ever change the messages passed between them, of course, but sometimes that’s required to gain the functionality you require. It’s all a trade-off.
I hope that helps, please let me know if you have any more questions.