Hey, I'm in the process of re-factoring an in-house GUI/waypoint/nav system that we use for product testing, and I had an architectural question that I wanted to ask here. Basically, the GUI allows the creation of waypoints and paths, and then robots may be sent on these paths. Currently, the GUI node itself is a fairly thin front-end to a "path manager" node, which does the work of persisting the waypoints and sending goals out to the navigation nodes on the individual robots. I'm looking at splitting off that functionality to a per-robot "planner", though, which would then access the data in the path manager, and be instructed directly by the GUI which waypoint to pursue (via a service). The thing is, that leaves the path manager as an extremely simple node. It's really just a data store with a couple of services which expose CRUD operations on structured data. What's the ROS Way when it comes to a thing like this? Looking to TF as an example, it seems that distributed may be a better model. Instead of building my "path manager" as a node, should it instead be a library which I include with every node which would need to access the shared data pool? Unlike TF, this is not data which has a time-based expiry, so there would need to be provision made for any node (for example, a new robot joining the system) to request a "full update." Is this a synchronization nightmare? Are there any other good examples of how data is persisted within ROS networks? Thanks. -- ** *Mike Purvis* | Software Architect | Clearpath Robotics, Inc. 295 Hagey Blvd. Waterloo, Ontario N2L 6R5 Canada *T: * +1 (800) 301-3863 x805 | *E:** *mpurvis@clearpathrobotics.com | *W:* clearpathrobotics.com ** * * *Your Unmanned Experts **TM*** * * This electronic communication (including any attachments) is CONFIDENTIAL AND LEGALLY PRIVILEGED. Any unauthorized use or disclosure is strictly prohibited. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Thank you.